@madsmtm Hey do you mind giving me a quick code review here? The unsafe usage is pretty straightforward but I'd feel better if someone double checked me.

winsafe's current version is using an MSRV of 1.87

Hi @Xaeroxe, winsafe author here. What MSRV are you aiming at?

@madsmtm Yes, I would love to have which as a depender of winsafe, but I do understand. Thank you for taking time to explain your reasons.

Anyway, since all you guys need is 2 rather simple calls, it seems that you're still adding unnecessary complexity with windows-bindgen and all this workspace setup.

You can reference the 2 functions directly:

#[link(name = "kernel32")]
unsafe extern "system" {
  pub fn GetBinaryTypeW(app_name: *const u16, bin_type: *mut u32) -> i32;
  pub fn GetLastError() -> u32;
}

That means zero dependencies for Windows.

Let me know if you need any help with this.

There's also another perspective to consider which is probably only apparent to me as a long term maintainer.

which doesn't get updated all that often, and that's for the better. Our users aren't expecting or wanting new features, they want a reliable way to perform a task which computers have been doing for decades. This isn't a place to try out new ideas, or be creative. Our users usually invoke a single simple function, and they are happiest when they don't have to think about which.

From a feature standpoint, which has been perfected. It is entirely plausible that no new major API changes happen ever again, and I would not view this as a tragedy. The reason that which requires maintenance work most often is to update or accommodate a new dependency. So my vision of the future for which is a future of utmost stability and very slow movement. I get closer to that future every time a dependency is removed.

Thank you for being understanding of this @rodrigocfd and I support your mission to make the usage of Windows APIs safer for us all!